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DETAILED ACTION 

1 . The amendment filed 8/9/2006 has been placed of record in the file. 

2. Claims 1, 10 5 15, 21, 25, 30, 37, 42, and 47 have been amended. 

3. The rejection of claims 1-14, 37-46, 59, 60, 67-69, and 73-75 under 35 U.S.C. 1 12 is 
withdrawn in view of the amendment. 

4. Claims 79-85 have been added. 

5. Claims 1-50, 59, 60, and 67-85 are now pending. 

6. The applicant's arguments with respect to claims 1-50, 59, 60, and 67-85 have been 
considered but are moot in view of the following new grounds of rejection. Although the 
independent claims have been amended, some of the applicant's arguments may still be relevant 
and are addressed below in the response to arguments section of this action. 

Response to Amendment 

7. Claims have been amended to remove certain limitations and to emphasize that the 
request packet includes data indicating that the status of the PPP sessions is requested. The 
amendment prove a change in scope to the independent claims as the independent claims have 
had limitations removed and/or now explicitly state an aggregated request packet which includes 
data indicating that the status of said PPP sessions is requested, and the like. However, none of 
the amended claims show a patentable distinction over the prior art of record as evidenced by the 
following new grounds of rejection. 
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Claim Objections 

8. Claim 82 is objected to because of the following informalities: 
• Claim 82 lacks a period. 

Appropriate correction is required. 

Claim Rejections - 35 USC § 112 

9. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

10. Claims 79, 80, and 82 are rejected under 35 U.S.C. 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

1 1 . Claims 79, 80, and 82 recite "wherein said receiving, said generating and said sending are 
performed in an aggregation device implemented as a single device" or the like. This clause 
makes the claims indefinite as it states that the sending step is performed in the aggregation 
device. In order to perform the step of "sending said aggregated request packet to a peer 
aggregation device" in a single aggregation device, the aggregation device would also have to 
include the peer aggregation device. This, of course, is nonsensical and is inconsistent with the 
applicant's disclosure and other claim language. Thus, the scope of claims 79, 80, and 82 is 
unclear. For the purpose of applying prior art it will be assumed that the aggregation device 
performs the act of sending and that the whole sending step is not performed in the aggregation 
device. For example, it will be assumed that the steps are "performed by an aggregation device 
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implemented as a single device" so as to show that the single aggregation device performs the 
step of sending but does not include the whole of the step within the device itself. 

Claim Rejections - 35 USC § 103 

12. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

13. Claims 1-4, 8-10, 14-16, 21-23, 25, 29, 30, 35-40, 42, 46-50, 59, 60, 69, 72, 75, and 78- 
85 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ketcham (U.S. Patent Number 
6,721,334) in view of Pereira (U.S. Patent Number 5,781,726). 

14. Ketcham disclosed a method for improving the efficiency of a packet-based network by 
using aggregate packets. In an analogous art, Pereira disclosed a method for managing polling 
traffic in a set of connection oriented sessions between end stations in a network. Both systems 
deal with data transfer from at least one end node, through a first router or edge device, through a 
second router or edge device, and to at least one second end node. 

15. Concerning the independent claims, although Ketcham describes a system in which 
different types of data packets can be aggregated together, he did not explicitly state the use of a _ 
keep-alive message or poll request. However, Pereira' s system is focused on the polling of 
point-to-point devices and explicitly states the use of a poll request from a first to a second end 
system and a poll response from the second to the first end system. It would have been obvious 
to one of ordinary skill in the art at the time of the applicant's invention to modify the system of 
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Ketcham by adding the ability to use keep-alive messages as the data packets as provided by 
Pereira. Here the combination would satisfy the need for an improved connection oriented 
protocol for systems that maintain a number of end users that share a common link. See Pereira, 
column 4, lines 12-17. This rationale also applies to those dependent claims utilizing the same 
combination. 

16. Thereby, the combination of Ketcham and Pereira discloses: 

• <Claim 1> 

A method of processing a plurality of keep-alive messages generated by a corresponding 
plurality of end systems, each of said plurality of keep-alive messages being designed to 
request the status of a corresponding point to point (PPP) session implemented on a 
communication network, said method comprising: receiving in an aggregation device 
(Ketcham, figure 4, item 308) said plurality of keep-alive messages (Pereira, column 4, 
lines 31-34); generating in said aggregation device an aggregated request packet which 
includes data indicating that the status of said PPP sessions is requested (Ketcham, 
column 7, line 62 through column 8, line 4, wherein the aggregated packet contains the 
poll requests as disclosed by Pereira); and sending said aggregated request packet to a 
peer aggregation device (Ketcham, figure 4, item 314). 

• <Claim 2> 

The method of claim 1, further comprising: receiving said aggregated request packet in 
said peer aggregation device (Ketcham, column 8, lines 15-22); indicating the status of 
said plurality of sessions in an aggregated reply packet (Pereira, column 6, lines 1-6, 
wherein Pereira's response polls may be aggregated at Ketcham's router 314); and 



Application/Control Number: 09/785,884 Page 6 

Art Unit: 2152 

sending said aggregated reply packet to said aggregation device (Ketcham, figure 4, 
inherently data packets can also flow from router 314 to router 308). 

• <Claim 3> 

The method of claim 1 , further comprising receiving in said aggregation device an 
aggregated reply packet from said peer aggregation device, wherein said aggregated reply 
packet indicates the status of at least some of said plurality of PPP sessions (Pereira, 
column 6, lines 1-6). 

• <Claim 4> 

The method of claim 3, further comprising sending from said aggregation device a proxy 
keep-alive reply message to one of said plurality of end systems originating a 
corresponding one of said keep alive-messages without waiting for said aggregated reply 
packet (Pereira, column 5, lines 45-47). 

• <Claim 8> 

The method of claim 1 , wherein said communication network is implemented using one 
of frame relay, ATM and IP networks (Ketcham, column 1, lines 33-48). 

• <Claim 9> 

The method of claim 1, wherein said aggregation device is one of a network access server 
and home gateway (Ketcham, column 4, lines 37-43). 

• <Claim 10> 

A method of processing an aggregated request packet in an aggregation device, wherein 
said aggregated request packet is received from a peer aggregation device and indicates 
that the status of a plurality of point-to-point sessions is requested, said method 
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comprising: examining said aggregated request packet to determine that the status of said 
plurality of point-to-point sessions is requested (Ketcham, column 8, lines 15-22, wherein 
the aggregated packet contains the poll requests as disclosed by Pereira); determining the 
status of each of said plurality of point-to-point sessions (Pereira, column 6, lines 1-6 and 
50-55); generating an aggregated reply packet indicating the status of said plurality of 
point- to-point sessions (Pereira, column 6, lines 1-6, wherein Pereira' s response polls 
may be aggregated at Ketcham's router 314); and sending said aggregated reply packet to 
said peer aggregation device (Ketcham, figure 4, inherently data packets can also flow 
from router 3 14 to router 308). 

• <Claim 14> 

The method of claim 10, wherein said aggregation device comprises one of a network 
access server (NAS) and a home gateway implemented in a communication network 
(Ketcham, column 4, lines 37-43). 

• <Claim 15> 

An aggregation device for processing a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, said aggregation device comprising: an input 
interface receiving said plurality of keep-alive messages (Ketcham, figure 4, item 308 
and Pereira, column 4, lines 31-34); a message aggregator coupled to said input interface, 
said message aggregator examining said plurality of message and generating data 
according to a format indicating that the status of said PPP sessions is requested 
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(Ketcham, column 7, line 62 through column 8, line 4, wherein the aggregated packet 
contains the poll requests as disclosed by Pereira); and an output interface sending an 
aggregated request packet on said communication network to a peer aggregation device, 
said aggregated request packet containing said data generated by said message aggregator 
(Ketcham, figure 4, item 314). 

• <Claim 16> 

The aggregation device of claim 15, further comprising an encapsulator encapsulating 
said data in a packet suitable for transmission on said communication network (Pereira, 
column 2, lines 19-25, wherein encapsulation is inherent to PPP). 

• <Claim21> 

An aggregation device for processing a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, said aggregation device comprising: first 
means for receiving said plurality of keep-alive messages (Ketcham, figure 4, item 308 
and Pereira, column 4, lines 31-34); means for generating an aggregated request packet 
which includes data indicating that the status of said PPP sessions is requested (Ketcham, 
column 7, line 62 through column 8, line 4, wherein the aggregated packet contains the 
poll requests as disclosed by Pereira); and means for sending said aggregated request 
packet to a peer aggregation device (Ketcham, figure 4, item 314). 
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• <Claim 22> 

The aggregation device of claim 21, further comprising second means for receiving an 
aggregated reply packet from said peer aggregation device (Ketcham, figure 4, inherently 
data packets can also flow from router 314 to router 308), wherein said aggregated reply 
packet indicates the status of at least some of said plurality of PPP sessions (Pereira, 
column 6, lines 1-6). 

• <Claim 23> 

The aggregation device of claim 22, further comprising means for sending a proxy keep- 
alive reply message to one of said plurality of end systems originating a corresponding 
one of said keep alive-messages without waiting for said aggregated reply packet 
(Pereira, column 5, lines 45-47). 

• <Claim 25> 

An aggregation device for processing an aggregated request packet, wherein said 
aggregated request packet is received from a peer aggregation device and indicates that 
the status of a plurality of point-to-point sessions are requested, said aggregation device 
comprising: means for examining said aggregated request packet to determine that the 
status of said plurality of point-to-point sessions is requested (Ketcham, column 8, lines 
15-22, wherein the aggregated packet contains the poll requests as disclosed by Pereira); 
means for determining the status of each of said plurality of point-to-point sessions 
(Pereira, column 6, lines 1-6 and 50-55); means for generating an aggregated reply packet 
indicating the status of said plurality of point-to-point sessions (Pereira, column 6, lines 
1-6, wherein Pereira's response polls may be aggregated at Ketcham's router 314); and 
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means for sending said aggregated reply packet to said peer aggregation device 
(Ketcham, figure 4, inherently data packets can also flow from router 314 to router 308). 

• <Claim 29> 

The aggregation device of claim 25, wherein said aggregation device comprises one of a 
network access server (NAS) and a home gateway implemented in a communication 
network (Ketcham, column 4, lines 37-43). 

• <Claim 30> 

An aggregation device for processing an aggregated request packet, wherein said 
aggregated request packet is received from a peer aggregation device and indicates that 
the status of a plurality of point-to-point sessions are requested, said aggregation device 
comprising: an input interface receiving said aggregated request packet (Ketcham, figure 
4, item 314, wherein the aggregated packet contains the poll requests as disclosed by 
Pereira); a de-encapsulator examining said aggregated request packet to determine that 
the status of said plurality of point-to-point sessions is requested (Ketcham, column 8, 
lines 15-22); a reply generator determining the status of each of said plurality of point-to- 
point sessions, and generating an aggregated reply packet indicating the status of each of 
said plurality of point-to-point sessions (Pereira, column 6, lines 1-6, wherein Pereira's 
response polls may be aggregated at Ketcham's router 314); and an output interface 
sending said aggregated reply packet to said peer aggregation device (Ketcham, figure 4, 
inherently data packets can also flow from router 3 14 to router 308). 
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• <Claim 35> 

The aggregation device of claim 30, further comprising a keep-alive processor coupled to 
said de-encapsulator, wherein said keep-alive processor examines said aggregated request 
packet to determine that status of point-to-point sessions is requested and causes said 
reply generator to generate said aggregated reply packet (Ketcham, column 8, lines 15-22 
and Pereira, column 6, lines 1-6). 

• <Claim 36> 

The aggregation device of claim 30, wherein said aggregation device comprises one of a 
network access server (NAS) and a home gateway implemented in a communication 
network (Ketcham, column 4, lines 37-43). 

• <Claim 37> 

A computer-readable medium carrying one or more sequences of instructions for causing 
a aggregation device to process a plurality of keep-alive messages generated by a 
corresponding plurality of end systems, each of said plurality of keep-alive messages 
being designed to request the status of a corresponding point to point (PPP) session 
implemented on a communication network, wherein execution of said one or more 
sequences of instructions by one or more processors contained in said aggregation device 
causes said one or more processors to perform the actions of: receiving in an aggregation 
device (Ketcham, figure 4, item 308) said plurality of keep-alive messages (Pereira, 
column 4, lines 31-34); generating in said aggregation device an aggregated request 
packet which includes data indicating that the status of said PPP sessions is requested 
(Ketcham, column 7, line 62 through column 8, line 4, wherein the aggregated packet 
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contains the poll requests as disclosed by Pereira); and sending said aggregated request 
packet to a peer aggregation device (Ketcham, figure 4, item 314). 

• <Claim 38> 

The computer-readable medium of claim 37, further comprising: receiving said 
aggregated request packet in said peer aggregation device (Ketcham, column 8, lines 1 5- 
22); indicating the status of said plurality of sessions in an aggregated reply packet 
(Pereira, column 6, lines 1-6, wherein Pereira's response polls may be aggregated at 
Ketcham 's router 314); and sending said aggregated reply packet to said aggregation 
device (Ketcham, figure 4, inherently data packets can also flow from router 314 to router 
308). 

• <Claim 39> 

The computer- readable medium of claim 37, further comprising receiving in said 
aggregation device an aggregated reply packet from said peer aggregation device, 
wherein said aggregated reply packet indicates the status of at least some of said plurality 
of PPP sessions (Pereira, column 6, lines 1-6). 

• <Claim 40> 

The computer-readable medium of claim 39, further comprising sending a proxy keep- 
alive reply message to one of said plurality of end systems originating a corresponding 
one of said keep alive-messages without waiting for said aggregated reply packet 
(Pereira, column 5, lines 45-47). 
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• <Claim 42> 

A computer-readable medium carrying one or more sequences of instructions for causing 
an aggregation device to process an aggregated request packet, wherein said aggregated 
request packet is received from a peer aggregation device and indicates that the status of 
a plurality of point-to-point sessions are requested, wherein execution of said one or more 
sequences of instructions by one or more processors contained in said aggregation device 
causes said one or more processors to perform the actions of: examining said aggregated 
request packet to determine that the status of said plurality of point-to-point sessions is 
requested (Ketcham, column 8, lines 15-22, wherein the aggregated packet contains the 
poll requests as disclosed by Pereira); determining the status of each of said plurality of 
point-to-point sessions (Pereira, column 6, lines 1-6 and 50-55); generating an aggregated 
reply packet indicating the status of said plurality of point- to-point sessions (Pereira, 
column 6, lines 1-6, wherein Pereira's response polls may be aggregated at Ketcham's 
router 314); and sending said aggregated reply packet to said peer aggregation device 
(Ketcham, figure 4, inherently data packets can also flow from router 314 to router 308). 

• <Claim46> 

The computer-readable medium of claim 42, wherein said aggregation device comprises 
one of a network access server (NAS) and a home gateway implemented in a 
communication network (Ketcham, column 4, lines 37-43). 

• <Claim 47> 

A communication network comprising: a first aggregation device (Ketcham, figure 4, 
item 308) receiving a plurality of keep-alive messages (Pereira, column 4, lines 31-34) 
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generated by a corresponding plurality of end systems, each of said plurality of keep- 
alive messages being designed to request the status of a corresponding point to point 
(PPP) session implemented on said communication network, said first aggregation device 
generating an aggregated request packet which includes data indicating that the status of 
said PPP sessions is requested (Ketcham, column 7, line 62 through column 8, line 4 5 
wherein the aggregated packet contains the poll requests as disclosed by Pereira), and 
sending said aggregated request packet (Ketcham, column 7, line 62 through column 8, 
line 4); and a peer aggregation device (Ketcham, figure 4, item 314) receiving said 
aggregated request packet and indicating the status of said plurality of sessions in an 
aggregated reply packet (Pereira, column 6, lines 1-6, wherein Pereira 5 s response polls 
may be aggregated at Ketcham's router 314), said peer aggregation packet sending said 
aggregated reply packet to said first aggregation device (Ketcham, figure 4, inherently 
data packets can also flow from router 314 to router 308), wherein each of said first 
aggregation device and said peer aggregation device is implemented as a single device 
(Ketcham, figure 4, items 308 and 314). 

• <Claim 48> 

The communication network of claim 47, wherein said first aggregation device is located 
at an edge of said communication networks (Ketcham, figure 4, item 308). 

• <Claim 49> 

The communication network of claim 48, further comprising an access network coupling 
said first aggregation device to said corresponding plurality of end systems, wherein said 
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plurality of keep-alive messages are received on said access network (Ketcham, figure 4, 
item 106). 

• <Claim 50> 

The communication network of claim 49, wherein said first aggregation device and said 
peer aggregation device respectively comprise a network access server (NAS) and a 
home gateway (Ketcham, column 4, lines 37-43). 

• <Claim59> 

The method of claim 1 , wherein said aggregation device is physically separate from said 
plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim 60> 

The method of claim 10, wherein said aggregation device is physically separate from said 
plurality of end systems (Ketcham, figure 4, item 308). 

• <Claim69> 

The method of claim 1 , wherein each of said PPP sessions terminates at a home gateway, 
and wherein said aggregation device comprises a switching device and is in the path of 
each of said PPP sessions from a corresponding one of said plurality of end systems to 
said home gateway (Ketcham, figure 4, item 308). 

• <Claim 72> 

The aggregation device of claim 30, wherein each of said PPP sessions terminates at a 
home gateway, and wherein said aggregation device comprises a switching device and is 
in the path of each of said PPP sessions from a corresponding one of said plurality of end 
systems to said home gateway (Ketcham, figure 4, item 314). 
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• <Claim 75> 

The computer readable medium of claim 37, wherein each of said PPP sessions 
terminates at a home gateway, and wherein said aggregation device comprises a 
switching device and is in the path of each of said PPP sessions from a corresponding one 
of said plurality of end systems to said home gateway (Ketcham, figure 4, item 308). 

• <Claim 78> 

The aggregation device of claim 21, wherein each of said PPP sessions terminates at a 
home gateway, and wherein said aggregation device comprises a switching device and is 
in the path of each of said PPP sessions from a corresponding one of said plurality of end 
systems to said home gateway (Ketcham, figure 4, item 308). 

• <Claim 79> 

The method of claim 1, wherein said receiving, said generating and said sending are 
performed in an aggregation device implemented as a single device (Ketcham, figure 4, 
item 308). 

• <Claim 80> 

The method of claim 10, wherein said examining, said determining, said generating and 
said sending are performed in said aggregation device implemented as a single device 
(Ketcham, figure 4, item 308). 

• <Claim81> 

The aggregation device of claim 2 1 , wherein said means for receiving, said means for 
generating and said means for sending are contained in said aggregation device 
implemented as a single device (Ketcham, figure 4, item 308). 
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• <Claim 82> 

The aggregation device of claim 25, wherein said means for examining, said means for 
determining, said means for generating and said means for sending are implemented in 
said aggregation device implemented as a single device (Ketcham, figure 4, item 308) 

• <Claim 83> 

The aggregation device of claim 30, wherein said input interface, said de-encapsulator, 
said reply generator and said output interface are contained in said aggregation device 
implemented as a single device (Ketcham, figure 4, item 308). 

• <Claim 84> 

The computer readable medium of claim 37, wherein said receiving, said generating and 
said sending are performed by said aggregation device implemented as a single device 
(Ketcham, figure 4, item 308). 

• <Claim 85> 

The computer readable medium of claim 42, wherein said examining, said determining, 
said generating and said sending are performed by said aggregation device implemented 
as a single device (Ketcham, figure 4, item 308). 
Since the combination of Ketcham and Pereira discloses all of the above limitations, claims 1-4, 
8-10, 14-16, 21-23, 25, 29, 30, 35-40, 42, 46-50, 59, 60, 69, 72, 75, and 78-85 are rejected. 

17. Claims 5-7, 11,13, 17-19, 24, 26, 28, 31, 32, 34, 41, 43, and 45 are rejected under 35 
U.S.C. 103(a) as being unpatentable over Ketcham in view of Pereira, as applied above, further 
in view of Chao et al. (U.S. Patent Number 5,964,837), hereinafter referred to as Chao. 
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1 8. The combination of Ketcham and Pereira disclosed a method for managing polling traffic 
in a set of connection oriented sessions between end stations in a network that uses aggregation 
of packets. In an analogous art, Chao disclosed a method of monitoring the topology of a 
network using polling and event-monitoring. Just as the combination of Ketcham and Pereira, 
Chao's system is utilized in point-to-point networks. 

19. Concerning claim 5, although the combination of Ketcham and Pereira did not explicitly 
state the use of a table to track the status of sessions in the network, Chao's main focus is a table 
or topology map, containing information about the operability of nodes in his system. It would 
have been obvious to one of ordinary skill in the art at the time of the applicant's invention to 
modify the combination of Ketcham and Pereira by adding a status table as provided by Chao. 
Here the combination satisfies the need for an improved method of monitoring a point-to-point 
network. See Chao, column 2, lines 15-24. This rationale also applies to other similar dependent 
claims utilizing the same combination. 

20. Thereby, the combination of Ketcham, Pereira, and Chao discloses: 
• <Claim5> 

The method of claim 4, further comprising: maintaining a remote status table in said 
aggregation device, wherein said remote status table indicates the status of sessions 
supported by said aggregation device (Chao, column 5, lines 46-50); updating said 
remote status table with the information in said aggregated reply packet (Chao, column 6, 
lines 1-13); and generating said proxy keep-alive reply according to said remote status 
table (Chao, column 6, lines 55-65). 
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• <Claim 6> 

The method of claim 5, wherein said proxy keep-alive message indicates that the 
corresponding session is alive/OK when a first keep-alive message is received for the 
corresponding session (Pereira, column 10, lines 29-38). 

• <Claim 7> 

The method of claim 6, further comprising initializing the status of each of said session to 
alive/OK such that said proxy keep-alive message in response to said first keep-alive 
message indicates alive/OK status (Pereira, column 10, lines 18-28). 

• <Claimll> 

The method of claim 10, wherein said determining comprises accessing a local status 
table which contains the status information of at least some of said plurality of point- to- 
point sessions (Chao, column 8, lines 52-58). 

• <Claim 13> 

The method of claim 10, wherein said generating comprises setting a bit to one logical 
value to indicate that a corresponding one of said plurality of sessions is OK/alive, and to 
another logical value to indicate that said corresponding one of said plurality of session 
not OK/alive (Chao, column 5, lines 50-53). 

• <Claim 17> 

The aggregation device of claim 16, further comprising: a remote status table indicating 
the status of sessions supported by said aggregation device (Chao, column 5, lines 46- 
50); and a de-aggregator receiving an aggregated reply packet from said peer aggregation 
device, wherein said aggregated reply packet indicates the status of at least some of said 
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plurality of PPP sessions, said de-aggregator updating said remote status table with the 
information in said aggregated reply packet (Chao, column 6, lines 1-13). 

• <Claim 18> 

The aggregation device of claim 17, further comprising a proxy reply unit sending a 
proxy keep-alive reply message to one of said plurality of end systems originating a 
corresponding one of said keep alive-messages without waiting for said aggregated reply 
packet (Pereira, column 5, lines 45-47). 

• <Claim 19> 

The invention of claim 18, wherein said aggregation device comprises a network access 
server (Ketcham, column 4, lines 37-43). 

• <Claim 24> 

The aggregation device of claim 23, further comprising: means for maintaining a remote 
status table in said aggregation device, wherein said remote status table indicates the 
status of sessions supported by said aggregation device (Chao, column 5, lines 46-50); 
means for updating said remote status table with the information in said aggregated reply 
packet (Chao, column 6, lines 1-13); and means for generating said proxy keep-alive 
reply according to said remote status table (Chao, column 6, lines 55-65). 

• <Claim 26> 

The aggregation device of claim 25, wherein said means for determining comprises 
means for accessing a local status table which contains the status information of at least 
some of said plurality of point-to-point sessions (Chao, column 8, lines 52-58). 
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• <Claim 28> 

The aggregation device of claim 25, wherein said means for generating sets a bit in said 
aggregated reply packet to one logical value to indicate that a corresponding one of said 
plurality of sessions is OK/alive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive (Chao s column 5, lines 50- 
53). 

• <Claim31> 

The aggregation device of claim 30, further comprising a local status table storing the 
status information of at least some of said plurality of point-to-point sessions, wherein 
said reply generator determines the status of said at least some of said plurality of point- 
to- point sessions by accessing said local status table (Chao, column 8, lines 52-58). 

• <Claim32> 

The aggregation device of claim 31, further comprising a session manager updating the 
status of said plurality of point-to-point sessions in said local status table (Chao, column 
7, lines 64-66). 

• <Claim 34> 

The aggregation device of claim 30, wherein said reply generator sets a bit in said 
aggregated reply packet to one logical value to indicate that a corresponding one of said 
plurality of sessions is OK/alive, and to another logical value to indicate that said 
corresponding one of said plurality of session not OK/alive (Chao, column 5, lines 50- 
53). 
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• <Claim41> 

The computer-readable medium of claim 40, further comprising: maintaining a remote 
status table in said aggregation device, wherein said remote status table indicates the 
status of sessions supported by said aggregation device (Chao, column 5, lines 46-50); 
updating said remote status table with the information in said aggregated reply packet 
(Chao, column 6, lines 1-13); and generating said proxy keep-alive reply according to 
said remote status table (Chao, column 6, lines 55-65). 

• <Claim 43> 

The computer-readable medium of claim 42, wherein said determining comprises 
accessing a local status table which contains the status information of at least some of 
said plurality of point-to-point sessions (Chao, column 8, lines 52-58). 

• <Claim45> 

The computer-readable medium of claim 42, wherein said generating comprises setting a 
bit to one logical value to indicate that a corresponding one of said plurality of sessions is 
OK/alive, and to another logical value to indicate that said corresponding one of said 
plurality of session not OK/alive (Chao, column 5, lines 50-53). 
Since the combination of Ketcham, Pereira, and Chao discloses all of the above limitations, 
claims 5-7, 1 1, 13, 17-19, 24, 26, 28, 31, 32, 34, 41, 43, and 45 are rejected. 

21 . Claims 12, 20, 27, 33, and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Ketcham in view of Pereira further in view of Chao, as applied above, further in view of 
Simpson ("RFC 1 66 1 : Point-to-Point Protocol," July 1 994). 
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22. The combination of Ketcham, Pereira, and Chao disclosed a method for managing polling 
traffic in a set of connection oriented sessions between end stations in a point-to-point network 
by aggregating packets and maintaining a status table. In an analogous art, Simpson disclosed an 
overview of the point-to-point protocol. 

23. Concerning claim 12, although the combination of Ketcham, Pereira, and Chao did not 
explicitly teach the use of a magic number associated with each session, Simpson taught a magic 
number for use with the point-to-point protocol. It would have been obvious to one of ordinary 
skill in the art at the time of the applicant's invention to modify the combination of Ketcham, 
Pereira, and Chao by adding a magic number as provided by Simpson. Again the combination 
satisfies the need for an improved method of monitoring a point-to-point network. See Chao, 
column 2, lines 15-24. This rationale also applies to other similar dependent claims utilizing the 
same combination. 

24. Thereby, the combination of Ketcham, Pereira, Chao, and Simpson discloses: 

• <Claim 12> 

The method of claim 10, wherein said generating comprises including a client magic 
number associated with each of said plurality of point-to-point sessions (Simpson, pages 
45-47). 

• <Claim 20> 

The aggregation device of claim 18, wherein said aggregated request packet contains a 
magic number related to each of the corresponding sessions (Simpson, pages 45-47). 
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• <Claim 27> 

The aggregation device of claim 25, wherein said means for generating includes a client 
magic number associated with each of said plurality of point-to-point sessions (Simpson, 
pages 45-47). 

• <Claim 33> 

The aggregation device of claim 30, wherein said reply generator includes in said 
aggregated reply packet a client magic number associated with each of said plurality of 
point-to-point sessions (Simpson, pages 45-47). 

• <Claim 44> 

The computer-readable medium of claim 42, wherein said generating comprises 
including a client magic number associated with each of said plurality of point-to-point 
sessions (Simpson, pages 45-47). 

Since the combination of Ketcham, Pereira, Chao, and Simpson discloses all of the above 

limitations, claims 12, 20, 27, 33, and 44 are rejected. 

25. Claims 67, 68, 70, 71, 73, 74, 76, and 77 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Ketcham in view of Pereira, as applied above, further in view of Rosenberg et 
al. ("An RTP Payload Format for User Multiplexing," May 1998), hereinafter referred to as 
Rosenberg. 

26. The combination of Ketcham and Pereira disclosed a method for managing polling traffic 
in a set of connection oriented sessions between end stations in a network that uses aggregation 
of packets. In an analogous art, Rosenberg disclosed a method of aggregating RTP data for 
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multiple users in a point-to-point system. Just as the combination of Ketcham and Pereira, 
Rosenberg's system is utilized in point-to-point networks. 

27. Concerning claims 67, 68, 70, 71, 73, 74, 76, and 77, although the combination of 
Ketcham and Pereira did not explicitly state that the aggregated message contains less data than 
the plurality of the non-aggregated messages together, this is a well known result in message 
aggregation. This is evidenced by Rosenberg whose system creates an aggregated message that 
is smaller than the sum of the original messages in order to improve packet efficiency. It would 
have been obvious to one of ordinary skill in the art at the time of the applicant's invention to 
modify the combination of Ketcham and Pereira by adding the ability for the message aggregator 
to generate less data in the aggregated message than the data forming the plurality of messages 
together as provided by Rosenberg. Here the combination satisfies the need for an improved 
connection oriented protocol for systems that maintain a number of end users that share a 
common link. See Pereira, column 4, lines 12-17. This rationale also applies to similar 
dependent claims utilizing the same combination. 

28. Thereby, the combination of Ketcham, Pereira, and Rosenberg discloses: 

• <Claim 67> 

The method of claim 1 , wherein said generating includes less data in said aggregated 
request packet than the data forming said plurality of keep-alive messages together 
(Rosenberg, page 2, paragraph beginning "On the other hand..."). 

• <Claim 68> 

The method of claim 67, wherein each of said plurality of keep-alive messages contains 
an identifier of a corresponding PPP session, wherein said generating comprises: 
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selecting said identifier of each of said plurality of keep-alive messages (Rosenberg, 
pages 3-5, section 2); and forming said aggregated request packet from said identifiers 
(Rosenberg, pages 3-5, section 2), whereby said aggregated request packet contains less 
data than said plurality of keep-alive messages together (Rosenberg, page 2, paragraph 
beginning "On the other hand..."). 

• <Claim70> 

The aggregation device of claim 30, wherein said reply generator includes less data in 
said aggregated request packet than the data forming said plurality of keep-alive 
■ messages together (Rosenberg, page 2, paragraph beginning "On the other hand. . ."). 

• <Claim71> 

The aggregation device of claim 70, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said reply 
generator operates to: select said identifier of each of said plurality of keep-alive 
messages (Rosenberg, pages 3-5, section 2); and form said aggregated request packet 
from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request 
packet contains less data than said plurality of keep-alive messages together (Rosenberg, 
page 2, paragraph beginning "On the other hand. . . "). 

• <Claim 73> 

The computer readable medium of claim 37, wherein said generating includes less data in 
said aggregated request packet than the data forming said plurality of keep-alive 
messages together (Rosenberg, page 2, paragraph beginning "On the other hand..."). 
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• <Claim 74> 

The computer readable medium of claim 73, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said generating 
comprises: selecting said identifier of each of said plurality of keep-alive messages 
(Rosenberg, pages 3-5, section 2); and forming said aggregated request packet from said 
identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request packet 
contains less data than said plurality of keep-alive messages together (Rosenberg, page 2, 
paragraph beginning "On the other hand ...")• 

• <Claim 76> 

The aggregation device of claim 21, wherein said means for generating includes less data 
in said aggregated request packet than the data forming said plurality of keep-alive 
messages together (Rosenberg, page 2, paragraph beginning "On the other hand. . ."). 

• <Claim 77> 

The aggregation device of claim 76, wherein each of said plurality of keep-alive 
messages contains an identifier of a corresponding PPP session, wherein said means for 
generating operates to: select said identifier of each of said plurality of keep-alive 
messages (Rosenberg, pages 3-5, section 2); and form said aggregated request packet 
from said identifiers (Rosenberg, pages 3-5, section 2), whereby said aggregated request 
packet contains less data than said plurality of keep-alive messages together (Rosenberg, 
page 2, paragraph beginning "On the other hand. . . "). 

Since the combination of Ketcham, Pereira, and Rosenberg discloses all of the above limitations, 

claims 67, 68, 70, 71, 73, 74, 76, and 77 are rejected. 
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Response to Arguments 

29. Some of the applicant's arguments appear to be repeated and have been addressed 
previously. For example, concerning the applicant's argument that Pereira teaches away, the 
applicant is directed to section 7 of the final action dated 6/27/2005 and section 1 1 of the 
advisory action dated 8/29/2005. 

30. Concerning determining that the status of the plurality of point-to-point sessions is 
requested, the applicant is reminded that Pereira's system is focused on the polling of point-to- . 
point devices and explicitly states the use of a poll request from a first to a second end system 
and a poll response from the second to the first end system. Clearly, in order to generate and 
send a poll response, it is determined that a poll request has occurred. In support of the argument 
that the combination of Ketcham and Pereira does not teach this determining step, the applicant 
has considered an excerpt from Ketcham but has not considered the combination as a whole. 
Here the applicant is reminded that one cannot show nonobviousness by attacking references 
individually where the rejections are based on combinations of references. See In re Keller, 642 
F.2d413,208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091,231 USPQ 375 
(Fed. Cir. 1986). 

31. In addition, the applicant has argued that claims rejected under 35 U.S.C. 103, but not 
explicitly discussed, are allowable based on the above arguments. Thus, claims disclosing 
similar limitations to the discussed claims and related dependent claims remain rejected under 
the same reasoning as presented above. 
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Conclusion 

32. The applicant's amendment necessitated the new grounds of rejection presented in this 
office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). The 
applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

33. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Victor Lesniewski whose telephone number is 571-272-3987. 
The examiner can normally be reached on Monday through Thursday. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Bunjob Jaroenchonwanit can be reached on 571-272-3913. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. \ 



Victor Lesniewski 
Patent Examiner 





Group Art Unit 2152 



